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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Access, Terminals, Transmission 
and Multiplexing (ATTM). 

The present document is part 12 of a multi-part IPCablecom 1.5 deliverable covering the Digital Broadband Cable 
Access to the Public Telecommunications Network; IP Multimedia Time Critical Services, as identified below: 



Part 1: 
Part 2: 

Pai-t 3: 

Part 4: 
Part 5: 

Part 6: 
Part 7: 
Part 8: 
Part 9: 
Part 10: 
Part 11: 
Part 12: 
Part 13: 
Part 14: 
Partis 
Part 16: 
Part 17: 
Part 18: 
Part 19: 
Part 20: 



'Overview"; 

'Architectural framework for the delivery of time critical services over Cable Television networks using 
cable modems"; 

'Audio Codec Requirements for the Provision of Bi-Directional Audio Service over Cable Television 
Networks using Cable Modems"; 

'Network Call SignalUng Protocol"; 

'Dynamic Quality of Service for the Provision of Real Time Services over Cable Television Networks 
using Cable Modems"; 

'Event Message Specification"; 

'Media Terminal Adapter (MTA Management Information Base (MIB)"; 

'Network Call Signalling (NCS) MIB Requirements"; 

'Security"; 

'Management Information Base (MIB) Framework"; 

'Media terminal adapter (MTA) device provisioning"; 

'Management Event Mechanism"; 

'Trunking Gateway Control Protocol - MGCP option"; 

'Embedded MTA Analog Interface and Powering Specification"; 

'Analog Trunking for PBX Specification"; 

'Signalling for Call Management Server"; 

'CMS Subscriber Provisioning Specification"; 

'Media Terminal Adapter Extension MIB"; 

'IPCablecom Audio Server Protocol Specification - MGCP option"; 

'Management Event MIB Specification"; 



ETSI 



ETSI TS 103 161-12 VI. 1.1 (2011-10) 



Part 21: "Signalling Extension MIB Specification". 

NOTE 1: Additional parts may be proposed and will be added to the list in future versions. 

NOTE 2: The choice of a multi-part format for this deliverable is to facilitate maintenance and future 
enhancements. 
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1 Scope 

1.1 Purpose 

The present document defines the Management Event Mechanism that IPCablecom elements can use to report 
asynchronous events that indicate malfunction situations and notification about important non-fault situation. 

Events are defined in the present document as conditions requiring the reporting of information to management systems 
and/or local log. 

A goal of IPCablecom is to maintain consistency with the DOCSIS® event reporting mechanism [i.2]. 

1.2 Introduction 

The present document is one of two documents that together define a framework for reporting Management Events in 
the IPCablecom architecture. 

The present document defines the general event reporting mechanism and framework. The mechanism consists of a set 
of protocols and interfaces that can be used by individual elements and components in the IPCablecom architecture. The 
present document defines how the SNMPv3 transport protocol, S YSLOG, local log, and the IPCablecom Management 
Event MIB are used to carry management event information to an event management system. 

This management event mechanism is further defined and supported by the Management Event Mechanism MIB as 
specified in [1] and [i.7] if the latter is implemented by the MTA. Consequently, each reference to the Management 
Event MIB in the present document will correspond to the MIB as defined either in [1], or alternatively, in [1] and [i.7]. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI TS 103 161-20: "Access, Terminals, Transmission and Multiplexing (ATTM); Integrated 

Broadband Cable and Television Networks; IPCablecom 1.5; Part 20: Management Event MIB 
Specification". 

[2] ETSI TS 103 161-11: "Access, Terminals, Transmission and Multiplexing (ATTM); Integrated 

Broadband Cable and Television Networks; IPCablecom 1.5; Part 11: Media Terminal Adapter 
(MTA) device provisioning". 

[3] ETSI TS 103 161-14: "Access, Terminals, Transmission and Multiplexing (ATTM); Integrated 

Broadband Cable and Television Networks; IPCablecom 1.5; Part 14: Embedded MTA Analog 
Interface and Powering Specification". 

[4] IETF RFC 3413: "Simple Network Management Protocol (SNMP) Apphcations", December 2002. 

[5] IETF RFC 3164: "The BSD Syslog Protocol", August 2001. 
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2.2 Informative references 



The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] ETSI TS 103 161: "Access, Terminals, Transmission and Multiplexing (ATTM); Integrated 

Broadband Cable and Television Networks; IPCablecom 1.5". 

[i.2] ANSI/SCTE 23-3 2010: "DOCSIS® 1.1 Part 3: Operations Support System Interface". 

[i.3] ETSI TS 103 161-2: "Access, Terminals, Transmission and Multiplexing (ATTM); Integrated 

Broadband Cable and Television Networks; IPCablecom 1.5; Part 2: Architectural framework for 
the delivery of time critical services over Cable Television Networks using Cable Modems". 

[i.4] Telcordia GR-474: "Network Maintenance: Alarm and Control for Network Elements". 

[i.5] ITU-T Recommendation M.3 100: "Generic Network Information Model", 1995. 

[i.6] ITU-T Recommendation X.733: "Open Systems Interconnection - Systems management: Alarm 

reporting function", 1992. 

[i.7] IETF RFC 5428: "Management Event Management Information Base (MIB) for PacketCable- and 

IPCablecom-Compliant Devices", April 2009. 

[i.8] IETF RFC 2573: "SNMP Applications". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 
network management: functions related to the management of data across the network 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

BSD Berkeley Software Distribution 

CDR Call Detail Record 

CMIP Common Management Information Protocol 

CMS Call Management Server 

CMTS Cable Modem Termination System 

DHCP Dynamic Host Configuration Protocol 

DNS Domain Name Server 

DOCSIS® Data Over Cable System Interface Specification 

FQDN Fully Qualified Domain Name 

IP Internet Protocol 

IPSec Internet Protocol Security 

MGC Media Gateway Controller 

MIB Management Information Base 

MSO Multi-System Operator 

MTA Media Terminal Adapter 

OSS Operations Systems Support 

PSTN Public Switched Telephone Network 

RKS Record Keeping Server 

SNMP Simple Network Management Protocol 

SYSLOG System Log 

NOTE: Used to grant Kerberos tickets. 
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TFTP Trivial File Transfer Protocol 

TGS Ticket Granting Server 

TLl Transaction Language! 

UDP User Datagram Protocol 

ID Identifier 

PRI Primary Rate Interface 

MSG Message Generation 

PBX Private Branch Exchange 

RADIUS Remote Access Dial-In User Service 

lANA Internet Assigned Number Association 

EMS Element Management System 

OSI Open Systems Interconnection 

UTC Universal Coordinated Time 

ACK Acknowledgement 

PID Packet identifier 

SRV Service Record 

AC Access Class 

KDC Key Distribution Center 

AS Access Server 

AP Access Point 

UPS Uninterruptible Power Source 



Void 



Background 



The IPCablecom architecture is an end-end broadband architecture that supports voice, video, and other multimedia 
services. The individual components that compose the IPCablecom architecture are defined in [i.3]. 

The OSS back office contains business, service, and network management components supporting the core business 
processes. The IPCablecom set of specifications defines a limited set of OSS functional components and interfaces to 
support MTA Device Provisioning [2] Event Messaging to carry billing information [i.l], and the Management Event 
Mechanism defined in the present document to carry fault and other data. 

In addition to the Management Event Mechanism, the IPCablecom architecture supports the following additional 
reporting mechanism: 

• IPCablecom Events Messages for billing information [i.l]. This reporting mechanism uses the RADIUS 
transport protocol, a pre-defined set of Event Message attributes (e.g. BillingCorrelationlD, 
CalledPartyNumber, TrunkGroupID, etc.), and the IPCablecom Event Messages data format to carry per-call 
information between IPCablecom network elements (CMS, CMTS, MGC) and a Record Keeping Server 
(RKS). For each call, the RKS combines all associated Event Messages into a single Call Detail Record (CDR) 
which may be sent to a back office billing, fraud detection or other system. Vendor-proprietary data attributes 
may be included along with the IPCablecom-defmed set of attributes in an IPCablecom Event Message. 

• Other Reporting Methods. It is possible that IPCablecom elements implement reporting methods specified in 
DOCSIS® MIBs, IPCablecom MIBs or other standard MIBs. It is possible that IPCablecom elements 
implement methods such as SNMPv3, CMIP, TLl. These event-reporting mechanisms are not defined in the 
present document. 
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6 IPCablecom Management Event Mechanism 

Functional Requirements 

The functional requirements addressed by the Message Event Mechanism specification are as follows: 

1) The event report must provide either the FQDN or IP address of the reporting device. 
NOTE 1: It is highly recommended that the device provide the FQDN. 

2) The IPCablecom management event reporting mechanism must support 2 types of events: IPCablecom- 
specific and Vendor-specific. 

3) The management event reporting mechanism must support the IPCablecom 1.5 Management Event MIB [1]. 
All the events that can be generated by the IPCablecom device must be included in the MIB table 
'pktcDevEventDescrTable'. 

4) The IPCablecom management event reporting mechanism must support the BSD syslog protocol [5]. 

5) The management event reporting mechanism must support SNMPv3/v2c Traps and SNMPv3/v2c Informs. 

6) The management event reporting mechanism must comply with SNMP Applications [4] since these MIBs 
provide the mechanism for distributing SNMPv3 traps and informs. The elements must support a mechanism 
to allow the element management system to map each event to a reported notification mechanism(s). For 
example: none, local, SYSLOG, SNMPv3/v2c Trap, SNMPv3/v2c inform. 

NOTE 2: Refer to the IPCablecom 1 .5 MTA Device Provisioning Specification [2] for more information about 
SNMP configuration. 

7) Each event must be uniquely identifiable to the point of origin such as a specific endpoint on an MTA. 

8) The capability should exist to map event IDs to priorities in the back office. 

9) IPCablecom elements must send a timestamp with each management event. 



10 

11 

12 

13 
14 

15 
16 

17 
18 

19 



IPCablecom elements must send a Severity level with each management event. Elements may use the Severity 
level within the network element to determine the order in which events are sent in compliance with Telcordia 
GR 474's clause 2.2.3 and clause 7.10 of the present document. 

The severity level of management events generated by the network element must be modifiable on the 
IPCablecom element by the management system. 

The display string of management events generated by the IPCablecom element must be modifiable on the 
network element by the management system. 

A default notification mechanism must be associated with each event. 

IPCablecom-specific event definitions should contain a NULL display string in order to reduce memory 
requirements on the IPCablecom element. 

Event definitions must contain a display string. 

Vendor-specific event definitions may contain a NULL display string in order to reduce memory requirements 
on the IPCablecom element. 

Event throttling mechanism must be configurable by the management system. 

All events are uniquely identified by vendor through the lANA assigned enterprise number. IPCablecom 
events use the lANA assigned enterprise number. 

An event must provide the Event ID of the event. 
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7 Management Event Reporting Mechanism 

The Management Event Mechanism and the associated Management Event MIB must be implemented on the MTA. 

The Management Event Mechanism and the associated Management Event Mechanism MIB may be implemented on 
any IPCablecom element such as the CMS, MGC, and others. 

7.1 Event Notification Categories 

All events delivered by (event mechanism document) fit into two main categories: 

• IPCablecom-specific 

• Vendor-specific 

IPCablecom-specific events are defined in the present document and referenced by concerned specifications whereas 
vendor-specific events are left to vendor implementation and are out of scope of the present document. 

Each Event has an associated Event ID as described in the next clause. IPCablecom-specific events are identical if their 
EventlDs are identical. The IPCablecom-specific EventlDs are specified by the IPCablecom Specifications, including 
the present document. For each particular vendor. Vendor-specific events are identical if the corresponding Event IDs 
are identical. The Vendor-specific EventlDs are defined by particular vendors and is out of scope for the present 
document. 

EXAMPLE: Two or more IPCablecom Events with the same Event ID (say 4000950100) are considered to be 
identical irrespective of the description or other parameters. 

Two or more Vendor-Specific Events, from the same vendor (say XYZ) with the same Event ID 
(say 10) are considered to be identical irrespective of the description or other parameters. 

For identical events occurring consecutively, the MTA may choose to store only a single event. In such a case, the event 
description recorded must reflect the most recent event. 

Aside from the procedures defined in the present document, event recording must conform to the requirements of [1] 
and Event Descriptions must not be longer than 127 characters. 

7.1 .1 Event ID Assignments 

• The EventID is a 32-bit unsigned integer. 

• IPCablecom-specific EventlDs must be defined in the range of 0x80000000 (decimal 2 147 483 648) to 
OxFFFFFFFF (decimal 4 294 967 295). 

• Vendor-specific EventlDs must be defined in the range of 0x00000000 (decimal 0) to 0x7FFFFFFF (decimal 

2 147 483 647). 

• Vendor-specific EventlDs must be unique for a particular vendor's enterprise number in sysObjectlD. 

7.2 IPCablecom Management Event Format 

The format of an IPCablecom Management Event is made up of the following information: 
Event Counter - indicator of event sequence 
Event Time - time of occurrence 

Event severity - severity of condition as defined in clause 7.5 
Event Enterprise number - Vendor specific enterprise number 
Event ID - determines event function 
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• Event Text - describes the event in human readable form 

• FQDN/Endpoint ID - describes the device FQDN and the specific endpoint associated with the event 

7.3 IPCablecom Management Event Access Method 

The IPCablecom event access method is defined through the use of SNMPv3 in the case of local log access and trap or 
inform access. The SYSLOG uses UDP packets to convey the event data. 

For local event log access, an EMS may send SNMP GET, GET-NEXT or GET-BULK requests to the IPCablecom 
element, accessing rows of the local event table. Each row must contain the event data in the format as defined 
in clause 7.1. 



The SYSLOG method of accessing events involves sending the events to a SYSLOG server via the UDP protocol to the 
UDP SYSLOG port a 
defined in clause 7.1. 



UDP SYSLOG port as defined in DOCSIS® specification [i.2]. This event data must follow the event data format as 



The SNMPv3 Trap and Inform access methods involve defining a notification within the IPCablecom Management 
Event MIB. The notification must contain the event data in the format as defined in clause 7.1. 

Any notification must be generated according to the entries in the associated SNMPv3 tables described in 

RFC 2573 [i.8] in a vendor dependent manner. These provide the ability to address one or more management systems, 

the option to send traps or informs, and specify the security requirements for each management system. 



7.4 Management Event ID 



IPCablecom management events are defined in an annex of IPCablecom specifications. Not all IPCablecom 
specifications define management events. Each management event described in the annex of an IPCablecom 
specification is assigned an IPCablecom Event ID. For a complete list of IPCablecom Event IDs, refer to annexes A and 
B in the present document. 



7.5 Management Event Severities 



Each event is assigned an initial (default) IPCablecom MultiMedia-centric Severity. The definitions for the IPCablecom 
MultiMedia-centric severities are loosely based on ITU-T Recommendation M.3100 [i.5] and OSI System Management 
Alarm Reporting Function X.733 [i.6]. IPCablecom expands on the definition provided in Telcordia's GR-474 (see 
clause 7.10) to include the following list: 

critical(l) - A service-affecting condition that requires immediate corrective action. 

major(2) - A service-affecting condition that requires urgent corrective action. 

ininor(3) - A non-service-affecting fault condition which warrants corrective action in order to avoid a more serious 
fault. 

warning(4) - A potential or impending condition which can lead to a fault; diagnostic action is suggested. 

information(5) - Normal event meant to convey information. 

Events, if they need to be cleared, must be cleared by other events. 

Each application (e.g. DOCSIS®, IPCablecom) has its own event space. There is no predetermined relationship of event 
severity defined or enforced between applications. 

When managing events that affect multiple applications two scenarios are possible. They are as follows: 

1) A particular application is considered the master. The master application sends the multiple destination events 
to its element manager. The application's element manages then broadcasts that event to all other element 
managers that are interested in that event. Severity translation is vendor dependent. 
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2) When an event occurs, every application interested in that event has its own event notification data template 
defined. An event is then sent out by each interested application according to its event notification data 
template. 

Event vendor in conjunction with the cable operators will implement its mechanism based on one of the scenarios 
described above. 

7.5.1 Changing Default Event Severities 

The default event severity must be changeable to a different value for each given event via the SNMP interface. 

7.6 Notification IVIechanism 

The notification mechanism for each event must be programmable via the SNMP interface. 
Each event must be able to be sent to one or more notification mechanisms. 
The notification mechanism definitions are as follows: 

• local: The event is stored locally on the device in which it is generated. The event can be retrieved via polling 
from the SNMP agent interface. 

• trap: The event is sent via the SNMPv3 trap mechanism to the targeted management systems. Due to the 
unacknowledged nature of the SNMPv3 trap mechanism, these event notifications are not guaranteed to be 
delivered to the targeted management systems. 

• inform: The event is sent via the SNMPv3 inform mechanism to the targeted management systems. Since the 
SNMPv3 inform mechanism is acknowledged, these events will be reliably transmitted to the targeted 
management systems. 

• syslog: The event is sent to the SYSLOG server. 

• none: No reporting action is taken, this is the equivalent of disabling the event. If "none" is specified, the other 
notification mechanism choices must be ignored. 



7.7 Local Log of Events 



The MTA must support local logging of events. The local log must be accessed via SNMP using the objects defined 
in [1]. A vendor may provide alternative access procedures. 

The MTA may implement local logging either in volatile memory, non-volatile memory or both. The index provided 
in [1] provides relative ordering of events in the log. The creation of local volatile and local-nonvolatile logs 
necessitates a method for synchronizing index values between the two local logs after reboot. If both volatile and non- 
volatile logs are maintained then the following procedure must be used after reboot: 

• The values of the index maintained in the local non-volatile log must be renumbered beginning with one. 

• The local volatile log must then be initialized with the contents of the local non-volatile log. 

• The first event recorded in the new active session's local-volatile log must use as its index, an increment by 
one of the last restored non-volatile index. 

Also, a reset of the log initiated through an SNMP set operation applied to the corresponding MIB objects of the 
Management Event MIB must clear both the local-volatile and local-nonvolatile logs. 
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7.8 Syslog 

All Syslog messages sent by an IPCablecom eMTA must comply with the following requirements: 

• It must use UDP as the transport mechanism with 514 as the destination port as defined in clause 2 of the BSD 
syslog protocol [5]. 

• It should use port 514 as the source port, as recommended in clause 2 of SNMP applications [5]. 



• 



It must comply with the Packet Format and Contents as defined in clause 4 of [5] as applicable to the 
origination of the message and use the format as described in the following clause. 



7.8.1 Syslog Message Format 

This clause defines the usage of the Syslog fields as defined in clause 4 of [5]. 

7.8.2 PRI Part of a Syslog Packet 

For the PRI part defined in clause 4.1.1 the facility to use must be: 

16 local use (localO) 
The severity is the severity as indicated in the definition of the Event message (0-7). 
The 'Priority Code' is as defined in clause 4.1 and ranges between 128 and 135 for IPCablecom. 

7.8.3 MSG Part of a Syslog Packet 

The MTA must include the following components: TIMESTAMP, HOSTNAME, TAG and the CONTEXT where: 

• TIMESTAMP is the time recorded by the MTA (This must reflect the time in UTC as obtained from the Cable 
Modem). 

• HOSTNAME must be the hostname received by the MTA in Option 12 of the DHCP ACK. (Refer to [2] for 
more details). 

• The TAG field must be set to the string 'MTA', without the quotes. 

• The PID field must be implemented and used as an 'Event Type Identifier'. The value must be: IPCABLECOM 
for all IPCablecom defined Event Messages. 

• A vendor-specific unique identifier for vendor-defined Event Messages. While the vendor-specific choices are 
out of scope of the present document, a vendor must use the same unique identifier for all messages 
originating from a device. 

• The CONTEXT part of the message must be formatted as follows: <eventID><correlationID> Description 
where: 

eventID must be the Event ID defined for each Event Message enclosed within angular braces. 

correlationID must the correlation ID generated by the MTA as defined in clause 5.4.5 of the Device 
Provisioning specification [2] . 

Description must be the description associated for the particular event as stored in the Management 
Event MIB [1]. 

EXAMPLE 1 : PRO V-EV- 1 is an IPCablecom defined 'Event', defined as follows. 



£75/ 



14 



ETSI TS 103 161-12 VI. 1.1 (2011-10) 



Table 1 : Example IPCablecom defined Event 



Event Name 


Event 
Priority 


Default Display 
String 


IPCablecom 
EventID 


Comments 


PROV-EV-1 


Critical 


"Waiting for DNS 
Resolution of 
Provisioning Realm 
Name" 


4000950100 


A DNS SRV Request has been transmitted 
for requesting the Provisioning Realm 
Information, but no response has been 
received from the DNS server. 



Assuming that the MTA has been requested to send SYSLOG messages (Refer to [2] and [1] for more information on 
turning on SYSLOG messages): 

• The Event Priority for critical is 2 (Refer to [1] for more information) and hence the 'Priority Code' is 130. 

• Since this is an IPCablecom Defined event, the 'Event Type Identifier' is IPCablecom. 

• The defined Event ID is 4000967295 and the assuming the default string has not been changed, the associated 
text is 'Waiting for Provisioning Realm Name DNS Resolution'. 

• Assume the hostname to be CL_mta_l and a correlation ID of 100. 

Thus, the event, if triggered will be sent as the following SYSLOG message: 

<130>Jan 1 09:00:00 CL_mta_l MTA[IPCABLECOM]:<4000850100><100> 
Waiting for DNS Resolution of Provisioning Realm Name. 

EXAMPLE 2: Assume the following hypothetical vendor-specific event defined by vendor 'XYZ Inc', with 
vendor ID 'XYZ'. 

Table 2: Example Vendor-specific Event 



Event Name 


Event 
Priority 


Display String 


Vendor 
Specific 
EventID 


Comments 


XYZ-EV-1 


Warning 


"AC Power Failure; 
running on battery" 


10 


AC Power Failure occurred and the 
device is running on battery power 



Again, assuming that the MTA has been requested to send SYSLOG messages (Refer to [2] and [1] for more 
information on turning on SYSLOG messages): 

• The Event Priority for warning is 4 (Refer to [1] for more information) and hence the 'Priority Code' is 132. 

• Vendor ID is 'XYZ' as stated in the example. 

• The defined Event ID is 10 and the display string as indicated is: 'AC Power Failure; running on battery'. 

• Assume the hostname to be CL_mta_2 and a correlation ID of 150. 
Thus, the event, if triggered will be sent as the following SYSLOG message: 

<132> Jan 1 1 21:04:03 CL_mta_2 MTA[XYZ]:<10><150>AC Power Failure; running on battery 



7.9 Event Throttling 



Throttling is implemented globally through a rate based threshold mechanism, as defined in the IPCablecom 
Management Event MIB [1]. 

Control of the throttling mechanism is through a MIB object that specifies one of four states. 

• Event generation inhibited - events defined through the event mechanism are no longer sent via syslog, traps, 
or informs. 

• Throttling inhibited - events are sent without any throttling. 
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• Dynamic thresholding enabled - threshold based throttling is enabled. 

• Manual thresholding enabled - manual intervention is required to resume event generation after crossing the 
initial threshold halts event generation. 

Manual intervention through setting a MIB object is used to resume event generation when manual thresholding is 
enabled. 

Inhibiting the generation of events must be handled through the use of the MIB objects, one to specify a number of 
events, and one to specify a time period over which those events are generated. The default frequency is defined as two 
events per second in the Management Event MIB. When event generation exceeds this rate, no more events are sent via 
SYSLOG, traps, or informs. The throttling of Local logging of events is vendor specific. 

Dynamic thresholding requires setting MIB objects to resume events. One object specifies the number of events, and the 
other is the time period object specified above. The default frequency is defined as one event per second. This defines 
the rate at which event generation is resumed. 

Threshold settings are not persistent, and must be reinitialized when the IPCablecom element reboots. 

In addition to this mechanism, vendors may support other throttling mechanisms. 

7.10 Severity and Priority Definition 

Severity is the degree of failure related to a specific event by a reporting device. Telcordia document 
GR-474-CORE [i.4]. Network Maintenance: Alarm and Control for Network Elements defines three degrees of 
severity: 



• 



Critical - Used to indicate a severe, service-affecting condition has occurred and that immediate corrective 
action is imperative, regardless of the time of day or day of the week. 

• Major - Used for hardware and software conditions that indicate a serious disruption of service or the 
malfunctioning or failure of important circuits. These troubles require the immediate attention and response of 
a craftsperson to restore or maintain system capability. The urgency is less than in critical situations because of 
a lesser immediate or impending effect on service or system performance. 

• Minor - Used for troubles that do not have a serious effect on service to customers or for troubles in circuits 
that are not essential to Network Element operation. 

Priority is the precedence established by order of importance or urgency. The back office manages the priority of how 
and when a particular event is serviced based on the severity of the reported event. According to Telcordia 
GR-474-CORE [i.4]. Network Maintenance: Alarm and Control for Network Elements, the following priority 
sequences for trouble notifications shall prevail: 

• Critical alarms have the highest priority and shall be serviced before any major or minor alarms. 

• Major alarms have higher priority than minor alarms and shall be serviced before any minor alarms. 

• Minor alarms shall be serviced before non-alarmed trouble notifications. 
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8 



IPCablecom Management Event Data Template 



In order to ensure multi-vendor interoperability of network management functionality, the specific meaning of 
IPCablecom management events are defined. Because the IPCablecom management events are based on conditions 
identified in IPCablecom specifications, management events are defined in the separate appendices of the present 
document. 

Table 3 shows the data required to describe the meaning of IPCablecom management events. The data contained in this 
table is for informational purposes only, this table will contain specific data when added as an annex to the present 
document. 

Table 3: Example Management Event Data 



Enterprise 
Number 


Event Name 


Default Severity 
for event raises 


Default Display 
String 


Comments 


Associated 
Events 


4491 


PL-EV-1 


informational 


"AC Power Fail" 


Telemetry pin 1 has been 
asserted. 


PL-EV-2 


4491 


PL-EV-2 


informational 


"AC Power Restore" 


Telemetry pin 1 has been 
de-asserted. 


PL-EV-1 


4491 


PROV-EV-1 


error 


"MTA Missing Name" 


The MTA was not provisioned 
with an FQDN. 


none 
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Annex A (informative): 
IPCablecom-defined Provisioning Events 

NOTE: For sake of simplicity and continuity Event IDs from 4000950100 upwards are reserved for Provisioning 
Events. 

Table A.I : Provisioning Events 



Event Name 


Default 

Severity for 

Event 


Default Display String 


Packet- 
Cable 
EventID 


Comments 


PROV-EV-1 


Error 


"Waiting for DNS 
Resolution of 
Provisioning Realm 
Name" 


4000950100 


A DNS SRV Request has been transmitted for 
requesting the Provisioning Realm Information, 
but no response has been received from the DNS 
server. 


PROV-EV-1.1 


Critical 


"Provisioning Realm 
Name unknown to the 
DNS Server" 


4000950101 


The DNS SRV Response from the DNS server did 
not resolve the Provisioning Realm Name. 


PROV-EV-2 


Error 


"Waiting for DNS 
resolution of 
IVlSO/Provisioning KDC 
FQDN" 


4000950200 


A DNS Request has been transmitted to request 
the MSO KDC (or Provisioning KDC) FQDN, but 
no response has been received. 


PROV-EV-2.1 


Critical 


"MSO/Provisioning KDC 
FQDN unknown to the 
DNS Server" 


4000950201 


The DNS Response from the DNS server did not 
resolve the MSO/Provisioning KDC FQDN. 


PROV-EV-3 


Error 


"Waiting For 
MSO/Provisioning KDC 
AS Reply" 


4000950S00 


A Kerberos AS Request has been transmitted to 
the MSO KDC (or Provisioning KDC), but no AS 
Response has been received. 


PROV-EV-2.2 


Error 


"Waiting for DNS 
resolution of 
Provisioning Server 
FQDN" 


4000950202 


A DNS Request has been transmitted to request 
the Provisioning Server FQDN, but no response 
has been received. 


PROV-EV-2.3 


Critical 


"Provisioning Server 
FQDN unknown to the 
DNS Server" 


4000950203 


The DNS Response from the DNS server did not 
resolve the Provisioning Server FQDN. 


PROV-EV-3.1 


Warning 


"MSO/Provisioning KDC 
did not accept the AS 
Request" 


4000950301 


The Kerberos MSO/Provisioning KDC rejected the 
AS-Request (KRB_ERROR). 


PROV-EV-4 


Error 


"Waiting For 
MSO/Provisioning KDC 
TGS Reply" 


4000950400 


A Kerberos TGS Request has been transmitted to 
the MSO KDC (or Provisioning KDC), but no TGS 
Response has been received. 


PROV-EV-4.1 


Warning 


"MSO/Provisioning KDC 
did not accept AS 
Request" 


4000950401 


The MSO/Provisioning KDC rejected the Kerberos 
AS Request (KRB_ERROR). 


PROV-EV-5 


Critical 


"Waiting for Provisioning 
Server AP Reply" 


4000950500 


A Kerberos AP Request has been transmitted to 
the MSO Provisioning Server (SNMP Entity), but 
no AP Response has been received. 


PROV-EV-5.1 


Warning 


"Provisioning 
Server/SNMP Entity 
rejected the Provisioning 
AP Request" 


4000950501 


The Provisioning Server/SNMP Entity rejected the 
Kerberos AP Request (KRB_ERROR). 


PROV-EV-6 


Critical 


"SNMPvS inform 
transmitted; Waiting for 
SNMPvS GET and/or 
SNMPvS set messages" 


4000950600 


SNMPv3 inform message has been transmitted 
and the device is waiting on optional (iterative) 
SNMv3 GET requests or a SNMPv3 set. 


PROV-EV-6.1 


Critical 


"SNMPv2c inform 
transmitted; Waiting for 
SNMPv2c GET and/or 
SNMPv2c set 
messages" 


4000950601 


SNMPv2c inform message has been transmitted 
and the device is waiting on optional (iterative) 
SNMv2c GET requests or a SNMPv2c set. 


PROV-EV-8 


Error 


"Waiting For DNS 
Resolution of TFTP 
FQDN" 


4000950800 


A DNS Request has been transmitted to request 
the TFTP FQDN, but no response has been 
received. 
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Event Name 


Default 

Severity for 

Event 


Default Display String 


Packet- 
Cable 
EventID 


Comments 


PROV-EV-8.1 


Critical 


"TFTP FQDN unknown 
to the DNS Server" 


4000950801 


The DNS Response from the DNS server did not 
resolve the TFTP FQDN. 


PROV-EV-9 


Critical 


"Waiting for TFTP 
Response" 


4000950900 


A TFTP request has been transmitted and no 
response has been received. (This could be for 
any TFTP Request during the download process). 


PROV-EV-9.1 


Critical 


"Configuration File Error 
- Bad Authentication" 


4000950901 


The config file authentication value did not agree 
with the value in pktcMtaDevProvConfigHash or 
the authentication parameters were invalid. 


PROV-EV-9.2 


Critical 


"Configuration File Error 
- Bad Privacy" 


4000950902 


The privacy parameters were invalid. 


PROV-EV-9.3 


Critical 


"Configuration File Error 
- Bad Format" 


4000950903 


The format of the configuration file was not as 
expected. 


PROV-EV-9.4 


Critical 


"Configuration File Error 
- IVIissing Parameter" 


4000950904 


Mandatory parameter of the configuration file is 
missing. 


PROV-EV-9.5 


Error 


"Configuration File 
Error- Bad Parameter" 


4000950905 


Parameter within the configuration file had a bad 
value. 


PROV-EV-9.6 


Error 


"Configuration File 
Error- Bad Linkage" 


4000950906 


Table linkages in the configuration file could not 
be resolved. 


PROV-EV-9.7 


Error 


"Configuration File 
Error- Misc." 


4000950907 


Configuration File error - Miscellaneous. 


PROV-EV-12 


Warning 


"Telephony KDC did not 
accept AS Request" 


4000951200 


The Telephony KDC rejected the AS-Request 
(KRB ERROR). 


PROV-EV- 
12.1 


Error 


"Waiting for Telephony 
KDC AS Reply" 


4000951201 


A Kerberos AS Request has been transmitted to 
the Telephony KDC, but no AS Response has 
been received. 


PROV-EV-13 


Error 


"Waiting For Telephony 
KDC TGS Reply" 


4000951300 


A Kerberos TGS Request has been transmitted to 
the Telephony KDC, but no TGS Response has 
been received. 


PROV-EV- 
13.1 


Warning 


"Telephony KDC did not 
accept TGS Request" 


4000951301 


The Telephony KDC rejected the Kerberos TGS 
Request (KRB ERROR). 


PROV-EV-14 


Critical 


"Waiting for CMS AP 
Reply" 


4000951400 


A Kerberos AP Request has been transmitted to 
the CMS (For IPSec), but no AP Response has 
been received. 


PROV-EV- 
14.1 


Warning 


"CMS rejected the AP 
Request (IPSec)" 


4000951401 


The CMS rejected the Kerberos AP Request 
(KRB ERROR). 


PROV-EV-15 


Informational 


"Provisioning Complete" 


4000951500 


The MTA successfully completed Provisioning. 


PROV-EV- 
15.1 


Warning 


"Provisioning Complete - 
Warnings" 


4000951501 


The MTA successfully completed Provisioning, 
but with warnings. 


PROV-EV- 
15.2 


Critical 


"Provisioning Complete - 
Fail" 


4000951502 


The MTA completed Provisioning, but there was a 
failure. 
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Annex B (normative): 
IPCablecom-defined Powering Events 

NOTE: For sake of simplicity and continuity Event IDs from 4000850100 - 4000950099 are reserved for 
Powering Events. 

MTAs that comply with [3] must support the following Powering events. 

All Powering events must be defined as a matched pair of "set" and "cleared" events. The eight Powering events may be 
redefined to support a meaning other than the battery-related meanings defined in the present document. If these 
Powering events are redefined, then the definition of the new meaning and any coordination between systems to support 
this new meaning is out of the scope of IPCablecom. 

The "set" and "clear" events for the alarm signals defined in [i.2] are summarized below. 

Telemetry Signal 1 - AC Fail 

• PL-EV-1: active alarm state of telemetry signal 1; default meaning "On Battery" and default severity minor 

• PL-EV-2: inactive alarm state of telemetry signal 1, default meaning "AC Restored"; PL-EV-2 always clears 
PL-EV-1 

Telemetry Signal 2 - Replace Battery 

• PL-EV-3: active alarm state of telemetry signal 2; default meaning "Battery Bad" and default severity minor 

• PL-EV-4: inactive alarm state of telemetry signal 2; default meaning "Battery Good"; PL-EV-4 always clears 
PL-EV-3 

Telemetry Signal 3 - Battery Missing 

• PL-EV-5: active alarm state of telemetry signal 3; default meaning "Battery Missing" and default severity 
minor 

• PL-EV-6: inactive alarm state of telemetry signal 3; default meaning "Battery Present"; PL-EV-6 always clears 
PL-EV-5 

Telemetry Signal 4 - LowBattery 

• PL-EV-7: active alarm state of telemetry signal 4; default meaning "Depleted Battery" and default severity 
minor 

• PL-EV-8: inactive alarm state of telemetry signal 4; default meaning "Battery Charging"; PL-EV-8 always 
clears PL-EV-7 
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Table B.1 : Powering Events 



Event 
Name 


Default 
Severity 


Default Display 
String 


IPCablecom 
EventID 


Comments 


Associated 
Events 


PL-EV-1 


Informational 


"On Battery" 


4000850100 


The UPS has detected an AC power 
failure and is operating off battery backup. 


PL-EV-2 


PL-EV-2 


Informational 


"AC Restored" 


4000850200 


The UPS has detected AC power restoral 
and is no longer operating off battery 
backup. 


PL-EV-1 


PL-EV-3 


Informational 


"Battery Bad" 


4000850300 


The UPS has determined that the battery 
has reached the end of its life expectancy 
and should be replaced. 


PL-EV-4 


PL-EV-4 


Informational 


"Battery Good" 


4000850400 


The UPS has detected the battery to be 
good. 


PL-EV-3 


PL-EV-5 


Informational 


"Battery IVIissing" 


4000850500 


The UPS does not detect the presence of 
a battery. 


PL-EV-6 


PL-EV-6 


Informational 


"Battery Present" 


4000850600 


The UPS detects that a battery is present. 


PL-EV-5 


PL-EV-7 


Informational 


"Depleted 
Battery" 


4000850700 


The UPS has determined that the 
remaining battery charge is low. There is 
only enough charge remaining to sustain 
operation for a short period of time. 


PL-EV-8 


PL-EV-8 


Informational 


"Battery 
Charging" 


4000850800 


The UPS detects that the battery has 
charged above the "battery low" threshold. 


PL-EV-7 
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